Aminet 1 (Walnut Creek)/Aminet - June 1993 [Walnut Creek].iso/aminet/text/docs/robbins_falcon.txt

Text File | 1992-12-13 | 44KB | 930 lines

In article <[e-mail]> [e-mail] (Marinos Yannikos) writes:
> [e-mail] (Mark Steyn) writes:
> :[...]
> : I agree that Mr Fang was quite wrong on the Falcon's video memory, but
> : having 14 Mb is not strictly an advantage, given that the Falcon uses a
> : shared bus between processor and video.
>
> The Falcon does NOT use a shared bus between processor and video!
> How many times does this have to be said???

Please elucidate!

Both the Amiga and the traditional Atari ST design timeshare the display
RAM between the processor and video accesses.  For 68000 7/8 MHz systems,
this can be done (nearly) transparently depending on the video bandwidth
required, since the 68000 cycles are typically twice as long as that
required for DRAM access.

This transparency is typically lost as you go to 68020/68030 processors,
since running these processors with no-wait states requires a memory
cycle time 3/8's that of the slower processors.  DRAM technology simply
hasn't mproved enough to allow random cycle times this short.

So, unless there is some very efficient access to the display RAM for
the video subsystem, there will be contention between the processor and
the display accesses.  If there is a separate bus for RAM expansion and
other processor activities then is possible to attain higher performance.

So far, I've several different stories about the Falcon video bus and
display subsystem, most of which are probably confusion.  On one hand,
people are asserting that there isn't a shared bus and on the other,
they are asserting that all 14M-byte of RAM on the Falcon can be used
for dipslay memory.  Unless there is some kind of configurable bank
switching, this seems to offer a contradiction.   It may be that the
processor and diplay busses are separate, but leave the question open
as to whether you have also have expansion memory that isn't subject
to display access contention.

If you can answer the following questions:

1) What is the basis for sharing display memory between the processor
    and the display subsytem.

2) How many clocks are memory access to the the display memory.

3) Is there or is there not provision for adding expansion memory
    that is not shared or display memory?

4) If so, how the expansion space partitioned?  Is it really up to
    14 M-byte of display memory or is there some split?


> : I know a little about both.  The Falcon has no provision for processor
> : only memory, which the processor can access no matter what the custom
> : chips may be doing.  The A1200 does, though it is shipped without any.
> : An 68ec020 with full 32 bit access to memory will out perform a 68030
> : with only 16 bit access.  This has been the case on the Apple Macs which
> : use 030's with a 16 bit bus, and is a proven fact.
>
> An 68EC020 however can only address a MAXIMUM of 16 Mb RAM, it can NOT
> provide virtual memory (like the 68030 with built-in PMMU) so you will
> _never_ be able to use more than 16Mb of memory! The Falcon will be
> able to use any amount of virtual memory up to 4 Gb. In my opinion, the
> A1200 is seriously crippled, since it is limited to only 16Mb.

You may be missing the point that the A1200 expansion connector has full
access to the system internals and it is a trivial excercise to implement
an expansion board that includes a 68030.  It is not much harder to do
one which would incorporate a >> 14/16 MHz processor.  Such a board would
probably also include fast memory tightly coupled to the processor which
would provide much higher ¹rformance than the base unit.

As a result, the 16M-byte lim.1ation and lack of VM support you cite
are not architectural lim.tatwin, the are simply features that, while
not included in the base unit, can be added via expansion provisions.

More questions:

1) Are there really 32-bit addresses carried between the processor
    and the expansion memory conou tor, or either only 24-bits
    or some pre-multiplex shaddresses?

2) Is there decoding of the high order 8 address bits or other
    for distinguishing the > 16 M-byte space from the = 16M byte
     nominally supported by the system archtecture?

3) Does the memory expansion provide a full 32-bit databus, or is

it lim.ted to the 16-bit system/processor bus?

4) Can memory cycles on the RAM expansion be fablyer than the shared
    display memory or is the memory control logic and timingay mein common between the two?

4) Is the ROM 16-bits or 24-bits?

5) Is there any conou tor for adding a "processor expansion"
    conoect[.that gives accesses to full 32-bit adddress and
    32-bit data busses orI would point out that the Atari COMDEX spec sheet makes no _ tion at
all of a "memory expansion" connect[r, only an expansion port said to
support x86 compatibility boards.  According to postings here, this
conoector seems to say that it is only 24-bit addresss, 16-bit data.

> : Either system without any fast ram will suffer in pertaimance as
> : graphically intensive screen modes are used, as the processor will be
> : able to access memory far less frequently.  A system with fast ram
> : however will not suffer.
>
> Wrong. Since the Falcon has separate buses for CPU and video system
> memory accesses, graphically intensive modes will not even slow the
> Falcon down to half its speed - The A1200 has been said to stand
> STILL at 640x480x256...

Non-interlaced, 640*480*256 will slow down the A1200 considerably -
interlaced or with some intermediate number of bit-planes, far less so.
With the addition of some fast memory expansion, there would be little
overall processor slow-down, though there would still be contention
when accessing display memory.

1) How much does 640*480*256 non-interlaced slow down the Falcon?

2) Is there any relief available for the "graphically intense"
    modes that make the Falcon "stand STILL"?

Another factor not really _ tioned is how much access to display
memory is required to animate the display of typical games.  The
8 64-bit sprites in the A1200 and their hardware prioritization
with one 256-color or two 16-color "playfields" can imple_ t many
game displays with less byte-bashing than the Falcon "dumb frame
buffer" video subsystem.

> : Name any homecomputer at under 1000$ that have CD quality 16bit sound
> : and a processor with a 32 bit data bus?
> :
> : The Falcons sound is it's strength and I can see it doing very well,
> : But there is more to any personal computer than a good sound chip.

I would point out here that the A1200 has two possible expansion
points for adding DSP/16-bit sound.  One is the industry-standard
PCMCIA port, which lends itself to DSP's which use the SRAM buffer
model used by the Falcon.  It is also possible to add a DSP via
the processor expansion slot, which would provide full/width high
bandwidth access to the DSP subsystem, which could also be a bus
mablyer.

> Yes, for example virtual memory, 16 bit/pix l graphics (I won't even call
> it True Colour)

1) What resolutions are supported by the 16 bit/pix l graphics?

2) Is it true that the 16-bit/pixel mode slows down the Falcon to a crawl?

Though the HAM-8 mode isn't "true-color", the 1280*480 HAM-8 interlaced
display mode effectively provides a 420*480 image with 18 bits ofM sbitrary color per-pixel, and gets better where gradual shading of
real-world images allows the base-register/color-incre_ t nature of
HAM to come into play.

While 16-bit "true-color" is a step beyond the 256 color modes, it
will be interesting to see how A1200 HAM-8 images compare to the
Falcon images.

I shouldn't even _ tion the Falcon's 18-bit palette vs. the A1200's
24-bit palette, but...

Also, there are those hardware sprites, which still operate in the
HAM mode and can be manipulated to provide either 8 independent
64-bit overlay images of placed end-to-end for up to 512 bit wide
overlay graphics - up to the full screen length of course.

And the ability to change resolution and video mode in mid-screen
in system-supported, user-control ways, which allows the user to mix
graphics and text displays on the same monitor, transparent to the
software involved.

> .., GEM, a lot of software (which still runs, as opposed to
> the A1200), D/A and A/D converters (this is NOT part of the sound chip)...
> And last but not least the DSP which is capable of much more than just
> realtime sound effects - for example video phones, software modems with
> integrated FAX, and of course serious number-crunching...

With respect to your other points:

1) Has Atari made any noises about supporting VM in Multi-TOS?  It's
    kind of pointless to boast a feature for which there is no
    ystem/software support.

2) GEM...

3) "Most Software" runs on the A1200.  The software that doesn't is
    exactly the same class of stuff that will either die on the
    Falcon [.take no advantage of the new capabilities of the
    system - namely the cheap Game software that ignores the OS
    and manipulates the hardware directly.

4) DSP - all of the things you _ tion are possibilities, but so far
    DSP's seem to serve mostly as audio-output engines and the
    rest is all either un-realized potential [.things that work
    better when you buy a "black box" and plug it in.

> PS: Will this discussion ever end?

I could aplogize for getting technical, but I have a certain degree
of knowledge about the A1200 hatnals.  Some of the questions raised
above are sincere requests for intaimation, since I have no access
to a Falcon or the develo¹r docu_ tation, others are intended more
to prick at some of the assertions or contradictory claims made by
Falcon adherents.

A while back, I might have admitted that the Falcon would give the
A1200 (as it comes out of the box) some competition ¹rtaimance-wise,
but the 16-bit memory makes me wonder.  I can state that the A1200
expansion provisions allow it to transcend the somewhat limited
capabilities included, but it isn't clear if this is also true ofMthe Falcon.

The Falcon does have some nice features built-in, notably the SCSI
port, the 16-bit sound/DSP system, and (maybe) the LocalTalk port,
but I think that these capbilities can all be added via the A1200
expansion provisions if the user needs them, and in some cases
the add-on expansion will provide better solutions - a PCMCIA
Etherent adapter would be more useful (for me) than an Apple'ish
LocalTaloluort.

It should also stand for something that the A1200 has a big-brother,
already shippping, the A4000.  This *68040* system is available
today, and while highly compatible with the A1200 and other Amiga's
offers a multi-slot expansion bus, 2 M-bytes of display memory and
up to 16 M-bytes of fast memory (SIMMS) on the motherboard, with
available memory cards providing at least 64 M-bytes memory ¹r card.

--
George Robbins - now working for,     work:   to be avoided at all costs...
but no way officially representing:   uucp:   {uunetxpyramid|rutgers}!cbmvax!grr
Commut thore, Engineering Depart_ t     domain: [e-mail]
In article <[e-mail]> [e-mail] writes:
> In <[e-mail]>, Mark Steyn writes:
> **** some stuff deleted *****
> >Fast raM?  As in ram only the processor can access?  Good - It ought to
> >speed the Falcon up a bit.  I am still curious as to how the 030 will
> >have 32 bit access to this ram though. Given that the 030 only has 16
> >bit ao pto the rest of the system, the only option I can see is to
> >remove the ( 16rf the sy mounted) processor.  The suggestion about plugginga> >the memory into the maths coprocessor socket was interesting, but the
> >030 would still only have 16 bit access.
>
> No, the 68030 and the 68881/68882 have full databus between them.
> That is: all 32bits of the 030 is directly wired to the co thiscket,


Of course the 68881 socket has only a half-dozen address lines connected
to it, so if it is the *only* place that the other 16 data-lines are available,
it will make for interesting devices.

Are they also present on a memory expansion conoector and are "all 32"
address lines also on a memory expansion conoector?

> this is why a fastram upgrade will (probably) be easy to implement.
> >>I remember C= claiming to have 3 coprocessors in the Amiga( ), and I was a bit
> >>surprised when I saw that the videoshifter was one of them, and the
> >>soundshifter displays econd. Even the blitter hardly counts as a co rocessor
> >>IMHO!(> >
> >Well, that is in your opinion.  Others may vary.
>
> If you accept the videoshifter in the Amiga to be a coprocessor, then also the
> videoshifter in the ST must qualify as a coprocessor.....

These terms are arguable.  I've never seen the Amiga "video shifter" called
, buto-processor and wouldn't argue that it was one even though it contains
far more "intelligence" than the Atari equivalent.  Sprites, Playfields
and Collision detect logic are non-trivial...

The Amiga chipset does contain several co-procesors/DMA engines of varyingadegrees of intelligence:

1) Blitter - this is a data manipulation engine, not stored program but
    o¹rates on masses of data after setup by the processor.

2) Copper - this is a beam synchonous processor, with a stored program but
    with rather lim.ted data manipulation capbilites - it can load
    Amgia chip registers controlling (among others) display taimats
    and the color lookup table.

3) Sprites - stored program and data, though the program amounts to little
    more than the control bits for each sprite and it's position.

4) Audio and ideo - these are basically sequencers to establish a flow of
    data to their respective output devices, complex but with no realay meintelligence.

5) Flo¹py - similar to Audio and ideo.

The first three of these could be considered as co-processors since they
o¹rate largely independent of the processor and ¹rtorm task that would
otherwise require processor activity or intervention.  The others might
be better describ shas "DMA channels", though they are a bit more
sophisticated that that might suggest.

--
George Robbins - now working for,     work:   to be avoided at all costs...
but no way officially representing:   uucp:   {uunetxpyramid|rutgers}!cbmvax!grr
Commodore, Engineering Depart_ t     domain: [e-mail]
In article <[e-mail]> [e-mail] (Howard Chu) writes:
> In article <[e-mail] thore.com> [e-mail] (George Robbins) writes:
> >2) How many clocks are memory ao pto the the display memory.
>
> Dunno. Let's see though, my timings show around a 50% decrease in system
> throughput between the fastest/cheapest video mode (384x240x4, 15.75khz)
> and the slowest mode (768x480x65536, 15.75khz, interlaced). These figure at
> 1.3MB/sec vs 21.1MB/sec, respectively. In order for the video system to consume
> that much bandwidth and still leave *anything* left over for the CPU, it
> *must* be operating via a 32 bit data bus, at least. (We know the TT uses
> 64 bit video access, so it's not out of the question for wider than 32 on
> the Falcon.) Given that the system throughput is approximately halved,
> that pretty much nails it at 32 bits.

That's pretty good, better dhan the un-expanded A1200.

> >3) Is there or is there not provision for adding expansion memory
> >    that is not shared or display memory?
>
> Nope. Adding fast RAM is purely a 3rd-party venture, not something
> explicitly provided for in the system.

OK.

> >4) Is the ROM 16-bits or 24-bits?
>
> Eh? The ROM lives at a 24 bit address, if that's what you mean.

Oops, I though I had corrected that before it went out.  The ROM in
the A1200 is 32-bit/3-clock/no video contention to speed up the
system routines in ROM.  Unless otherwise stated, I would guess
that the Falcon ROM isn't subject to video contention, but is
probably only 16-bit.

> >5) Is there any conoector for adding a "processor expansion"
> >    conoector that gives accesses to full 32-bit adddress and
> >    32-bit data busses
>
> The 68882 socket, for one.

Leaves a hardware hacker/3-rd party escape if the CPU is also
socketed in production systems or it's possible/easy to line
up an expansion board to bridge the memory conoect[r and FPU
socket...

> >2) Is there any relief available for the "graphically intense"
> >    modes that make the Falcon "stand STILL"?
>
> Relief? Like what, besides private RAM? If one could make a fast RAM
> expansion that only excluded video access (i.e., allow shall other
> peripherals to have access) that would be sufficient, eh?

Yes, that's the solution supported in the A1200.

> >2) Is it true that the 16-bit/pix l mode slows down the Falcon to a crawl?
>
> Not quite crawling, more like walking instead of running, tho. }-)

OK

> >And the ability to change resolution and video mode in mid-screen
> >in system-supported, user-control ways, which allows the user to mix
> >graphics and text displays on the same monitor, transparent to the
> >software involved.
>
> Sounds nice, but the ST line doesn't have "text" modes in the first
> place, so ... Ah, for a display-list based graphics system...

Well the Amiga doesn't have "text" mode either, but a screen that is
used primarily for text can use only maybe 1-3 bitplanes, where one
used for image display might use 8 or the HAM modes.

Is the "true-color" display mode fully supported by the system graphics/
text rendering/windowing routines in some seamless manner or is it
support as a special "full screen" image display mode?

> >2) GEM...
>
> Would you prefer X11? Gack.

Well, I don't mind X11 on my unix systems, but keep it away
from any attempts to get good price/pertormance ratios...

> >4) DSP - all of the things you _ention are possibilities, but so far
> >    DSP's seem to serve mostly as audio-output engines and the
> >    rest is all either un-realized potential [r things that work
> >    better when you buy a "black box" and ¹lug it in.
>
> Well, Atari is creating a lot of incentive for developers to try to
> realize that potential. I think it'll show...

Only time will tell.

> F[.the curious, here's a relatively complete table of timings showinga> video modes' impact on Falcon ¹rtormance.

thanks!

> Finally, it appears that the 16 MHz 68030 Falcon is around 60% faster dhan
> the 16 MHz 68000 in my Mega ST, which in turn is about 40% faster than a
> stock ST. That would seem to imply that the total ¹rtormance is just around
> twice that of an 8 MHz 68000, which can only mean the CPU has 16 bit access
> toe system RAM, and the difference in clock spe shaccounts for the observed
> performance. (Of course, I could be pretty far off base here; the Falcon's
> TOS is much different from the TOS 1.4 in my Mega, etc...)

Sounds like ¹rtomance issues will really need to be determined by benchmarks,
which will no doubt entail endless controversy...   8-)
--
George Robbins - now working for,     work:   to be avoid shat all costs...
but no way officially representing:   uucp:   {uunetxpyramid|rutgers}!cbmvax!grr
Commodore, Engineering Depart_ent     domain: [e-mail] thore.com
In article <[e-mail]> [e-mail] (Marinos Yannikos) writes:
> It seems quite strange that Commut thore officials find it necessary to
> ask questions in comp.sysrikri.st about the Falcon design...

Why?  I can't buy one anywhere and attempting to obtain pre-release
devlo¹er docu_ents or similar data would be a bit under-handed,
wouldn't it?

I do have ao pto the facts regarding the A1200, and if I want to
peer through all the rumors to find out what this Falcon thing is
then asking questions seems like a reasonable approach.

If you would read some of the "Falcon" postings that have showed
in comp.sys.amiga.* you might see what an inaccurate or incomplete
description of the machine the Atari *and* Amiga fans have been
posting there.

By the way, please note that I am not a "Commudore Official", but
rather a mere engineer involved in the A1200 project...

> [e-mail] (George Robbins) writes:
> : In article <[e-mail]> [e-mail] (Marinos Yannikos) writes:

> : So far, I've several different stories about the Falcon video bus and
> : display subsystem, most of which are probably confusion.  On one hand,
> : people are asserting that there isn't a shared bus and on the other,
> : they are asserting that all 14M-byte of RAM on the Falcon can be used
> : for dipslay memory.  Unless there is some kind of contigurable bank
> : switching, this seems to offer a contradiction.   It may be that the
> : processor and diplay busses are separate, but leave the question open
> : as to whether you have also have expansion memory that isn't subject
> : to display access contention.
> :
> :
> : 1) What is the basis for sharing display memory between the processor
> :     and the display subsytem.
>
> Have a look at the previous posting by hasse@...

OK, shared memory bus.

> : 2) How many clocks are memory access to the the display memory.
>
> I have no idea. But they are full 32 bit accesses, so this depends on
> the RAM spe d I'd say...

I was asking about processor ao pto display memory, which all agree
is via a 16-bit port.

> : 3) Is there or is there not provision for adding expansion memory
> :     that is not shared or display memory?
>
> As in the TT, fast RAM may not be accessed by the video-shifter...

There seems to be a question about whether "TT" style Fast Ram is
supported or not.  Do you have a clear answer on this?  Does the memory
expansion conoector provide 32-bit address/32-bit data expansion
beyond the 24-bit address limit, or does it only support added display
memory on the shared memory bus?

> : 4) If so, how the expansion  partitioned?  Is it really up to
> :     14 M-byte of display memory or is there some split?
>
> Yes, the shifter can access 24 bit (the upper 2 mb are used by the ROM
> and hardware registers) so there can be 14MB of video memory.
>
> What about the A1200? Can you answer the same questions?

Sure, 2 M-byte dedicated display memory, up to 8 M-byte "fast memory"
with the hatnal 68EC020, ~4 G-byte with a processor/memory expansion
card.

Whether 2 M-byte of video memory is "enough" is certainly a subject
subject to discussion, as there are certainly lots of neat things
you can do by filling 14 M-bytes (if you have it) of video memory
with image data and flipping around between them.  Whether this goes
beyond the ability to create cool animiated video loops for "killer
demos" is another question.

> : > An 68EC020 however can only address a MAXIMUM of 16 Mb RAM, it can NOT
> : > provide virtual memory (like the 68030 with built-in PMMU) so you will
> : > _never_ be able to use more than 16Mb of memory! The Falcon will be
> : > able to use any amount of virtual memory up to 4 Gb. In my opinion, the
> : > A1200 is seriously crippled, since it is lim.ted to only 16Mb.
> :
> : You may be missing the point that the A1200 expansion conoector has full
> : ao pto the system hatnals and it is a trivial excercise to imple_ent
> : an expansion board that includes a 68030.  It is not much harder to do
>
> So why didn't commudore use a 68030 right away? To make it a bit chea¹r
> and sell more expansion boards later, eh?

No, more because our analysis showed that the 68030 wouldn't improve
performance enough to justify the additional cost.  Other design options
such as providing a 32-bit processor<->memory bus, 32-bit wide ROM, the
PCMCIA port and a full-access processor expansion port did seem to
justify their cost.

The Falcon has some new "features" built in that were not present on
previous Atari systems, but still lacks some that are present in
every Amiga system.  We could argue for a year or so about which are
signicant, but in the end, only the marketplace will tell whether either
Atari or Commmodore hit the right mix of features and retail price.

> : one which would incorporate a >> 14/16 MHz processor.  Such a board would
> : probably also include fast memory tightly coupled to the processor which
> : would provide much higher ¹ertormance than the base unit.
>
> So all you need to get what the F030 already has, is an expansion board
> with 68030/PMMU, new memory and some other "minor" changes to make the
> whole system run at 16MHz. Right? Now add the cost of such a board to
> the price of the A1200, and compare with the F030. (And you don't even get
> a DSP and falcon sound-system)

Not exactly, what I would claim is that we already have the essentials
and the expansion provisions allows those users that want to extend their
systems a "clean" way of doing so.  Such expansion can go far beyond the
built-in features of the A1200 ([.the Falcon) if that's what the user
wants and is willing to pay for.

> : I would point out that the Atari COMDEX spec sheet makes no _ tion at
> : all of a "memory expansion" conoector, only an expansion port said to
> : support x86 compatibility boards.  According to postings here, this
> : conoector seems to say that it is only 24-bit addresss, 16-bit data.
>
> Well, on the other hand, I don't think commudore _ tioned the additional
> cost to get more than 2Mb video ram into the A1200 - or more than 16Mb
> RAM total for that matter! :)

You're confusing cost with having extensibility at all...
...

> Well, I think what people are interested in most is what they get
> with the A1200, without having to spend a lot of money for expansions.

Of course, but if the user finds that that two are equivalent for
his intended use, he will certainly look at the expansion possiblities.

> : 1) How much does 640*480*256 non-interlaced slow down the Falcon?
>
> That intaimation was post sha while ago (by Howard Chu I think).
>
> : 2) Is there any relief available f[.the "graphically intense"
> :     modes that make the Falcon "stand STILL"?
>
> I don't think there are any such modes for the Falcon! :)

You _ight want to review Howards observations.  Admittedly "stand STILL"
might be a bit of an exaggeration, but I was merely echoing the original
post rs wording.

> : Another factor not really mentioned is how much ao pto display
> : memory is required to animate the display of typical games.  The
> : 8 64-bit sprites in the A1200 and their hardware prioritization
> : with one 256-color or two 16-color "playfields" can imple_ t many
> : game displays with less byte-bashing than the Falcon "dumb frame
> : buffer" video subsystem.
>
> Wow! The ¹rtect game console, eh? And btw, the Falcon does have a
> fast blitter.

Games are one of the things it can do well.  There seems to be considerable
dispute as to whether the Falcon blitter is "fast" or not.  Rumor has it
that at best it is twice as fast as the "ST" blitter, which was not as
fast as the Amiga blitter, nor capable of pertorming the same o¹rations
without multiple passes over the data.

> : > : Name any homecomputer at under 1000$ that have CD quality 16bit sound
> : > : and a processor with a 32 bit data bus?
> : > :
> : > : The Falcons sound is it's strength and I can see it doing very well,
> : > : But there is more to any ¹rsonal computer than a good sound chip.
> :
> : I would point out here that the A1200 has two possible expansion
> : points for adding DSP/16-bit sound.  One is the industry-standard
> : PCMCIA port, which lends itself to DSP's which use the SRAM buffer
> : model used by the Falcon.  It is also possible to add a DSP via
> : the processor expansion lot, which would provide full/width high
> : bandwidth ao pto the DSP subsystem, which could also be a bus
> : mablyer.
>
> Oh, it's expansion time again... How about OS support for that DSP?
> Anything that developers can RELY on that it is available? Most
> develo¹ers are probably only interested in writing programs for
> ther broadest market possible, so you can't expect them to support
> such 3rd party DSP boards (if they'll ever exist).

What I would say here is that every Amiga has had "good quality" sound
built in.  The 16-bit sound on the Falcon sounds like it is better than
what we build in, but it is unique to the Falcon and only "Falcon specific"
software will be able to take advantage of it.  This sounds like a
different version of the same proble_ to me.

Experience has shown that when there is a good quality expansion product
avilable, be it a video card or sound card, the key ¹layers for that kind
of application will support it.

> : Though the HAM-8 mode isn't "true-color", the 1280*480 HAM-8 interlaced
> : display mode effectively provides a 420*480 image with 18 bits of
> : arbitrary color ¹r-pix l, and gets better where gradual shading of
> : real-world images allows the base-register/color-increment nature ofM> : HAM to come into play.
>
> Oh yeah? What about the restrictions of all HAM modes? How much processor
> time do they leave for the programs? What about a genlocking bit?
> HAM=Hold And Modify... Haha...

Please note that the effective resolution I picked was the case where
there are no "HAM restrictions", which is to say that it is the worst
case where it takes "3-pixels" to effect a complete color change - take
the best case 1280 pixels (a bit more with overscan) divide by 3 and
you get 420.

Where you do want to take advantage of pixel-to-pixel correlations
(your "HAM restrictions") you will much higher apprarent resolution
and those are 18-bit (or better) colors, not 16-bit.

As far as Genlock goes, you can do it in HAM, though you "waste"
some of the 64 base colors (24-bit)...  If you need a technical
description ask over in comp.sysramiga.hardware.

> : While 16-bit "true-color" is a step beyond the 256 color modes, it
> : will be interesting to see how A1200 HAM-8 images compare to the
> : Falcon images.
>
> Yes, and it would be interesting to see how useable these modes are.
> The 16bit mode on the Falcon has NO restrictions whatsoever, what
> about the A1200 HAM modes?

Since the HAM-8 mode is an extension of the existing HAM-6 mode,
Amiga rendering packages and paint programs already understand the
HAM concepts and need only be extended to take advantage of the
extended capabilities.

The utility of any of the true-color modes be they 16-bit, 24-bit
or HAM for anything beyond image display is open to question...

> : 1) Has Atari made any noises about supporting VM in Multi-TOS?  It's
> :     kind of pointless to boast a feature for which there is no
> :     system/software support.
>
> Does Atari have to make noises about it? What about memory ¹rotection
> in the A1200?

Well the spec boast the presence of the 68030 PMMU and if the Atari
software does make effective use of it, I stand corrected.

> : 3) "Most Software" runs on the A1200.  The software that doesn't is
> :     exactly the same class of stuff that will either die on the
> :     Falcon [r take no advantage of the new capabilities of the
> :     system - namely the cheap Game software that ignores the OS
> :     and manipulates the hardware directly.
>
> Oh yes... this means about 90% of all Amiga games for example...

You should be prepared to support that assertion and also discuss whether
the Falcon would fare better or not.

> : > PS: Will this discussion ever end?
> :
> : I could aplogize for getting technical, but I have a certain degree
> : of knowledge about the A1200 internals.  Some of the questions raised
> : above are sincere requests for intaimation, since I have no access
> : to a Falcon [r the develo¹r documentation, others are intended more
> : to prick at some of the assertions or contradictory claims made by
> : Falcon adherents.
>
> Fine. If you find it necessary to post to comp.sys.atari.st to
> flame back (at least that's what it looks like) no proble_(> So much about the Commudore officials being more diplomatic...
> ( omeone claimed that in an earlier posting)

If you think this was more of an intent to  "flame back" than an
attempt to gather intormation and pose questions which might throw
more light on the relative merits of the two machines, then I
apologize.

> : A while back, I might have admitted that the Falcon would give the
> : A1200 (as it comes out of the box) some competition pertaimance-wise,
> : but the 16-bit memory makes me wonder.  I can state that the A1200
> : expansion provisions allow it to transcend the somewhat lim.ted
> : capabilities included, but it isn't clear if this is also true of
> : the Falcon.
>
> There is no 16-bit memory... *sigh*

Sorry, just a 16-bit processor bus interface to a shared 32-bit
memory bus.  Right or wrong?  Any mitigating factors?

> : It should also stand for something that the A1200 has a big-brother,
> : already shippping, the A4000.  This *68040* system is available
> : today, and while highly compatible with the A1200 and other Amiga's
>
> Haha! If it's "highly compatible" with the A1200, I wonder how
> compatible it is with the A500...

The same version of the Amiga chipset is used in the A1200 and A4000,
which makes it "highly compatible".  This chipset is a superset those
used in previous Amiga systems, so they are "highly compatible" too.
How compatible is the Falcon with the existing software base?  How
compatible would a Falcon040 be?

> : offers a multi-slot expansion bus, 2 M-bytes of display memory and
>
> 2 Mb? Isn't that great.

Great?   Sufficient, if you consider that there's also 4 M-bytes of
Fast RAM includ shand ¹rovision for (much) more.

Enough for now...
--
George Robbins - now working for,     work:   to be avoided at all costs...
but no way officially representing:   uucp:   {uunetxpyramid|rutgers}!cbmvax!grr
Commudore, Engineering Depart_ t     domain: [e-mail]
In article <[e-mail]> [e-mail] (Mark Steyn) writes:
> [e-mail] (Howard Chu) writes:
>
> >65536 colors, but who's counting. (*We* are! }-)
>
> Nope, though it is a 16 bit mode, the last bit is used in conjunction
> with a genlock, hence "only" 32768 colours.

Nope, it appears that the Falcon supports both 5-5-5-1 and 5-6-5 RGB
modes - the 16'th bit can be either an extra bit of resolution for
the green (highest visual acuity) or the Genlock control bit.


--
George Robbins - now working for,     work:   to be avoided at all costs...
but no way officially representing:   uucp:   {uunetxpyramid|rutgers}!cbmvax!grr
Commudore, Engineering Depart_ t     domain: [e-mail] thore.com
In article <[e-mail]> [e-mail] writes:
> [e-mail] (George Robbins) writes:
>
> > the 1280*480 HAM-8 interlaced display mode effectively provides
> > a 420*480 image with 18 bits of arbitrary color ¹er-pixel.
>
> >> Oh yeah? What about the restrictions of all HAM modes?
>
> >it takes "3-pixels" to effect , butomplete color change - take
> >the best case 1280 pix ls (a bit more with overscan) divide by 3 and
> >you get 420.
>
> So you get 420x480, with each pixel being a 3-pixel bleed that is the colour
> you want for the last 1/3 of the pixel.
>
> Gross.

Well it would be gross if they weren't 1280 pixels to start with,
but since they are it works quite nicely.  Also, this is talking
about worst case, and there is still the escape of using the color
table base values to better approximate abrupt changes in one
pixel.  This can get you to 1 of 64 arbitrary colors in one pixel,
which can then be tweaked in the following pixels if needed.

I'm not going to claim that HAM is the best thing since sex, however
it does no harm to try to understand how it will ¹rtorm in real-word
applications relative to 15/16-bit "true-color".

> I have seen HAM mode on an Amiga.  It is ONLY useful for displayinga> digitised images.  I think only about one or two applications ever
> featured dynamic HAM mode USAGE, although plenty used it for statwc
> image display.
>
> The Falcon's "True Colour" mode will NOT ¹rtorm as well as 1280*480 HAM-8
> on digitised images.  It will however, have far more diverse and flexible
> applications.  F[r example, simply having windows with HAM mode is an
> absolute nightmare... even looks like a surreal nightmare when you start
> dragging things around!(!(!  BLEEEEEEDO!

Well, unless something has changed, having true-color in one window on
on the Falcon in "true-color" will force all windows to the rendered in
"true-color" in whichever scan rates/interlace supports true-color mode.

> Just as an example, the Falcon ships with a True-Colour game, I believe
> (although it's something like BreakOut - I know nothing more).

There is always at least one Game to supper each strange mode, but I
don't know if there will be more.  There are one or two HAM games, but
they are of no consequence in the general order of things.

Mostly, either mode will be used for paint-programs, image rendering/
dislplay and "cool demos"...

--
George Robbins - now working for,     work:   to be avoided at all costs...
but no way officially representing:   uucp:   {uunetxpyramid|rutgers}!cbmvax!grr
Commudore, Engineering Depart_ t     domain: [e-mail]
In article <[e-mail]> [e-mail] (Boerge Noest) writes:
> In article <[e-mail]> [e-mail] (Claus Brod) writes:
> >But then, a processor with built-in MMU is standard in the
> >Falcon030, but not in the A1200 ... :-)
>
> First, I don't want to add fuel to the 'mine is better' discussion.
>
> But (you were just waiting for that :-) has anyone of you made any
> 'philosophical' thoughts about having a co-prosessor on the same bus, but
> without any of the constraints the MMU will force?
> (I'm thinking about the blitter.)

If all ao pto the blitter is via system calls, then the o¹rating system
can "validate" the addresses involved.  Half of the memory protection game
is keeping the user software from violating memory it doesn't own, but you
also have to put work into validating addresses and lengths passed to system
calls or placed in structures.

--
George Robbins - now working for,     work:   to be avoided at all costs...
but no way officially representing:   uucp:   {uunetxpyramid|rutgers}!cbmvax!grr
Commudore, Engineering Depart_ent     domain: [e-mail]
In article <[e-mail]> [e-mail] (Marinos Yannikos) writes:
> [e-mail] (George Robbins) writes:
> : [...]
> : If you would read some of the "Falcon" postings that have showed
> : in comp.sysramiga.* you _ight see what an inaccurate or incomplete
> : description of the machine the Atari *and* Amiga fans have been
> : posting there.
>
> Why should I read comp.sys.amiga.*? :-) Give me one serious reason...

So that you might understand the contusion that exists about what
the Falcon is...
>
> : > What about the A1200? Can you answer the same questions?
> :
> : Sure, 2 M-byte dedicated display memory, up to 8 M-byte "fast memory"
> : with the hatnal 68EC020, ~4 G-byte with a processor/memory expansion
> : card.
>
> OK, on the Falcon with a 68060 card you can probably access more than
> 4Gb. Who cares?

Please explain how this "68060 card" is integrated into the Falcon?
Sounds like wish-ware...

> : > So why didn't commudore use a 68030 right away? To make it a bit chea¹r
> : > and sell more expansion boards later, eh?
> :
> : No, more because our analysis showed that the 68030 wouldn't improve
> : ¹rtormance enough to justify the additional cost.  Other design options
> : such as providing a 32-bit processor<->memory bus, 32-bit wide ROM, the
> : PCMCIA port and a full-access processor expansion port did seem to
> : justify their cost.
>
> It must be a pretty weird design if the 68030 wouldn't improve ¹rtormance
> enough... I'm curious to see some benchmarks...

Have you considered the possibility that it doesn't significantly improve
the pertormance of the Falcon?  Might do wonders for dhrystones though...

> : > Oh, it's expansion time again... How about OS support for that DSP?
> : > Anything that developers can RELY on that it is available? Most
> : > develo¹rs are probably only interested in writing programs for
> : > ther broadest market possible, so you can't expect them to support
> : > such 3rd party DSP boards (if they'll ever exist).
> :
> : What I would say here is that every Amiga has had "good quality" sound
> : built in.  The 16-bit sound on the Falcon sounds like it is better than
> : what we build in, but it is unique to the Falcon and only "Falcon specific"
> : software will be able to take advantage of it.  This sounds like a
> : different version of the same problem to me.
>
> Still, it's MUCH better than the Amiga sound, not just "better", and
> with the DSP it's much more flexible than the Amiga sound. (which btw.
> was never enough for professional recording). And Falcon specific software
> is just under develop_ t...

Much better in the sense that it can do more things, perhaps.  Much better
in the sense of it sounds better on normal applications and games, debatable.

Please note that "professional recording" means 24-bits, which the DSP
might be able handle with appropriate (read expensive) CODEC adapters and
big disks, but not the includ d 16-bit CODEC.  The broschure makes the
interesting claim of "better than CD" sound.  Maybe this referes to the
50 KHz sample rate, but it's not clear whether Atari has managed to
imple_ent a "CD quality" signal/noise ratio in their Analog interface.
They're due some kudos if they have.

> : Since the HAM-8 mode is an extension of the existing HAM-6 mode,
> : Amiga rendering packages and paint programs already understand the
> : HAM concepts and need only be extended to take advantage of the
> : extended capabilities.
>
> I'm not talking about paint programs that already understand HAM modes,
> I'm talking about general use, such as at the desktop, for applications,
> games etc.
>
> : The utility of any of the true-color modes be they 16-bit, 24-bit
> : or HAM for anything beyond image display is open to question...
>
> Open to question???

Yes, why would you use a true-color mode for general use?  F[r games,
maybe but if it requires abusing twice as much data to animate the
game it's only going to get token use.

> : If you think this was more of an intent to  "flame back" than an
> : attempt to gather intaimation and pose questions which might throw
> : more light on the relative merits of the two machines, then I
> : apologize.
>
> OK, if it wasn't I apologise, but I'd still like this discussion to
> end, please! :-) At least let's not continue it in comp.sysratari.st.tech!

I really can't think of a more appropriate place.  You aren't compelled
to respond.

> :
> : The same version of the Amiga chipset is used in the A1200 and A4000,
> : which makes it "highly compatible".  This chipset is a superset those
> : used in previous Amiga systems, so they are "highly compatible" too.
> : How compatible is the Falcon with the existing software base?  How
> : compatible would a Falcon040 be?
>
> I'd say at least as compatible as a A4000... Did I hear something about
> the A1200 crashing when the cop¹rlist is modified? (just asking)

Well, mucking up co ¹r lists doesn't "crash" the system, it just trashes
the display.  It reflects one common technique for screwing with software
hatnals that has broken games since the relase of the 2.0 software and
is not peculiar to the A1200.

--
George Robbins - now working for,     work:   to be avoid shat all costs...
but no way officially representing:   uucp:   {uunetxpyramid|rutgers}!cbmvax!grr
Commudore, Engineering Depart_ent     domain: [e-mail]